[-empyre-] capacious processing



> Processing is perfect for introductory programming. Secondly,
> Processing is not a "graphic app",

Do you mean it is a programming language?

> nor does it produce a narrow visual
> expression.

Great. You must have given some thought to this, Marius, and what it might
take to produce a tool that does not produce narrow visual expression. I
would be very interested to hear your thoughts on the matter.

> I've been using Processing as a tool to teach computational design and
> generative form to students with a primarily visual background.
> Because of
> its simplified Java syntax it allows beginners to get coding within
> minutes, without having to learn about compilers, IDEs or a complicated
> environment like Flash. Students can then gradually advance to more
> abstract concepts like advanced data structures and object oriented
> programming. There are now a number of people developing
> extensions to the
> Processing libraries by providing "plug-in" classes with new
> functionality.
>
> One of the central concepts behind Processing is to make students
> "unlearn"
> the hardwired software metaphors of environments like Flash, Director or
> Photoshop.

What metaphors are you thinking of? In particular, I'm interested in the
Director and Flash metaphors you don't employ. Are there other metaphors you
*do* adopt?

Instead, one starts from scratch. This has the virtue of
> allowing many possible expressions, although it might be limiting for
> professional use because there is none of the infrastructure that
> professional software has for working with digital media files.
>
> At the moment, I would recommend using Processing for learning, teaching
> and developing prototypes. This is what the tool has been
> developed to do.
> However, there are already a number of people using Processing to create
> software pieces for online viewing, VJ performances, sound synthesis etc.

Why just prototypes? Director has certain limitations that I know of that
make it hard to develop multi-open-document applications (max 1000
simultaneously instantiated sprites is one of the limitations, as is true
support for dynamic creation/destruction of sprites).

ja








This archive was generated by a fusion of Pipermail 0.09 (Mailman edition) and MHonArc 2.6.8.